-
Notifications
You must be signed in to change notification settings - Fork 254
Backport Proof of Space perf improvements from abundance #3712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…ace (nazar-pc/abundance#406) Using the entire ab-proof-of-space as at commit: nazar-pc/abundance@6d56b48 And merge changes from ab-proof-of-space/Cargo.toml into subspace-proof-of-space/Cargo.toml.
Using the entire ab-chaha8 as at commit: nazar-pc/abundance@6d56b48
🛡️ Immunefi PR ReviewsWe noticed that your project isn't set up for automatic code reviews. If you'd like this PR reviewed by the Immunefi team, you can request it manually using the link below: Once submitted, we'll take care of assigning a reviewer and follow up here. |
|
The benchmark failure might take some time to fix, and I've run out of time today. Looks like the benchmarks expect Proof of Space to return Ok, but instead it's returning an error. The "check individually" failure is trivial, just some missing dead code annotations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that miri annotations may not be necessary since this repo doesn't run tests under Miri (abundance does to have additional guarantees that unsafe code maintains invariants, but some tests are too slow to run regularly in CI or impractical to run in general, hence corresponding annotations).
Similarly no-panic ensures compiler can figure out the code can't possibly panic at compile time, which allows for better optimizations, but this repo doesn't run corresponding tests, so not sure how useful it is to port over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a review but not confident in my review yet due to big number of changes in the first PR Commit itself.
Ignored tests and benchmarks for this review
Some of the later commits can be merged up as they add no extra benefit for review
|
|
||
| impl ab_core_primitives::solutions::SolutionPotVerifier for ChiaTable { | ||
| fn is_proof_valid(seed: &PosSeed, challenge_index: u32, proof: &PosProof) -> bool { | ||
| Tables::<K>::verify_only(seed, challenge_index.to_le_bytes(), proof) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the behaviour same for verify and verify_only ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
verify follows Chia API and returns the quality back. verify_only doesn't compute the quality, just verification. The verification itself is reused and is identical. You can see the logic in the fn verify, it has exactly one branch.
|
|
||
| // TODO: More idiomatic version currently doesn't compile: | ||
| // https://github.com/Rust-GPU/rust-gpu/issues/241#issuecomment-3005693043 | ||
| #[allow(clippy::needless_range_loop)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
confused here with this clippy allowed warning. Is this allow required ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is required for GPU implementation, but not for CPU. It is just pulled from the codebase where GPU support is already partially implemented and this was needed to make it both compile and not complain.
I'm trying to minimise the diff with abundance, so the next backport is easier.
I'd like to keep them separate so they're easier to revert, if we need to do that in the next backport. It's also useful to have the backport steps clearly listed. Edit: I squashed some similar commits |
…o subspace versions
838b880 to
fa44a46
Compare
|
|
||
| // Check that proof of space is valid | ||
| if !PosTable::is_proof_valid( | ||
| if !<PosTable as SolutionPotVerifier>::is_proof_valid( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nazar-pc in the subspace benchmarks, I'm getting an InvalidProofOfSpace error here:
SubspaceExtension::<T>::do_check_vote(&signed_vote, TransactionSource::InBlock) SubspaceExtension::<T>::do_check_vote(&signed_vote, TransactionSource::InBlock)
I'm not sure if:
- my changes in this PR have broken verification (I've checked and none of my commits should change the result)
- there's an unexpected incompatibility in the abundance source commit
- the benchmark is wrong in some way, and this code is stricter
- the abundance code doesn't handle unlimited solution ranges
- some other issue
Does anything seem obvious to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing obvious from a quick look, but I have not audited the code. Try to start a local node and farmer, see if it can produce blocks. Even with changed logic for constructing tables, if challenge is derived the same way, verification should succeed. Something is significantly wrong if verification doesn't pass.
You can also add verification right after proof generation and dump the seed and challenge index for which verification fails. You can then update tests to check that particular seed both here and in abundance repo to see where things do not match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the hard-coded vote.data, which is decoded using VoteData, I get a failure in ShimTable (only used for tests) at:
| return false; |
Which means no solution was found.
This happens because ab-proof-of-space inverted the ShimTable logic, I've reverted to the current Subspace logic, and the benchmarks pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not changing the vote data to match updated shim implementation then? Also if benchmarks are running shim implementation instead of Chia, that doesn't seem right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not changing the vote data to match updated shim implementation then?
I wasn't in the mood for mucking around with binary files 😂
But seriously, if we are just going to change to the real implementation in the next PR, there's no point in changing the vote data in this one as well.
Also if benchmarks are running shim implementation instead of Chia, that doesn't seem right.
I had that thought as well. Happy to move to the real implementation in another PR.
If there's any expensive setup we can put it outside the benchmarked code. (Or in a OnceCell if it's very expensive.)
@vedhavyas @jfrank-summit what do you think?
2e8bf24 to
84dc9fa
Compare
84dc9fa to
c019daa
Compare
This PR backports the latest compatible Proof of Space changes from abundance, including some API refactors, including all relevant files up until commit:
nazar-pc/abundance@6d56b48
It should be reviewed one commit at a time.
The copied code is best reviewed by:
The copied code includes:
Various minor fixes are then made to get it to compile and pass CI:
Cargo.tomlbuild filesI also added some extra tests and benchmark debugging.
Code contributor checklist: